Interface for Defining User Directed Partial Graph Execution

ABSTRACT

Executing a user defined portion of an executable graph. The method includes providing to a user a graphical representation of an executable graph, the executable graph comprising executable modules. The method further includes receiving from the user a selection of a sub-portion of the executable graph. The method further includes executing the user selected sub-portion of the graph in isolation from other portions of the executable graph.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of and priority to U.S. ProvisionalPatent Application Ser. No. 62/212429 filed on Aug. 31, 2015 andentitled “User Directed Partial Graph Execution,” which application ispress incorporated herein by reference in its entirety.

BACKGROUND Background and Relevant Art

Computers and computing systems have affected nearly every aspect ofmodern living. Computers are generally involved in work, recreation,healthcare, transportation, entertainment, household management, etc.

One method of programming computers involves the use of graphicalexecution workflows. In a graphical execution workflow, functionalmodules or nodes of a graph are created which perform various functions.The modules of the graph are coupled to each other through edges. In atypical scenario, data will flow downstream through the modules of agraph by the edges. Thus, upstream modules will create data, which isthen passed to downstream modules, which can operate on the data tocreate new data, which can be farther passed on to still furtherdownstream modules.

When developing applications using graphical execution workflows,portions of a graph may be modified. To test the modified portions, thegraph is re-executed so that data from upstream modules can flow to themodified portions of the graph. Thus, for relatively small changes to agraph, large amounts of execution of other parts of the graph may takeplace to test the small changes

The subject matter claimed herein is not limited to embodiments thatsolve any disadvantages or that operate only in environments such asthose described above. Rather, this background is only provided toillustrate one exemplary technology area where some embodimentsdescribed herein may be practiced.

BRIEF SUMMARY

One embodiment illustrated herein includes a method that includes actsfor executing a user defined portion of an executable graph. The methodincludes providing to a user a graphical representation of an executablegraph, the executable graph comprising executable modules. The methodfurther includes receiving from the user a selection of a sub-portion ofthe executable graph. The method further includes executing the userselected sub-portion of the graph in isolation from other portions ofthe executable graph.

Additional features and advantages will be set forth in the descriptionwhich follows, and in part will be obvious from the description, or maybe learned by the practice of the teachings herein. Features andadvantages of the invention may be realized and obtained by means of theinstruments and combinations particularly pointed out in the appendedclaims. Features of the present invention will become more fullyapparent from the following description and appended claims, or may belearned by the practice of the invention as set forth hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and otheradvantages and features can be obtained, a more particular descriptionof the subject matter briefly described above will be rendered byreference to specific embodiments which are illustrated in the appendeddrawings. Understanding that these drawings depict only typicalembodiments and are not therefore to be considered to be limiting inscope, embodiments will be described and explained with additionalspecificity and detail through the use of the accompanying drawings inwhich:

FIG. 1A illustrates a graph execution system;

FIG. 1B illustrates alternative user interface elements for the graphexecution system;

FIG. 1C illustrates selection of additional graph elements for executionof a partial graph;

FIG. 1D illustrates selection of a subset of graph modules by a user;

FIG. 2 illustrates user interface elements of the graph executionsystem;

FIG. 3 illustrates additional user interface elements;

FIG. 4 illustrates a run history that can be displayed to a user in agraphical user interface;

FIG. 5 illustrates additional user interface elements;

FIG. 6 illustrates a method of executing a user selected portion of anexecutable graph; and

FIG. 7 illustrates a method of a user defined portion of an executablegraph.

DETAILED DESCRIPTION

In a graphical execution workflow, there are situations where a usermight not want to execute a graph in its entirety. Embodiments hereinallow a user to select a sub-portion of a graph for execution. Necessaryinput state(s) can be made available to execute the sub-portion of thegraph using relevant cached data as inputs, using random data as inputs,by allowing the user manually input data, by suggesting to the useradditional portions of the graph to execute, etc. In addition toallowing for quick iterations on graph modifications, this approachallows users to purposely exclude specific modules from execution. Forexample, if a module executing has side-effects that the user does notwant to manifest unless an entire graph is executed the user can excludethis module from execution. Execution of a graph stops when an entireuser-selected subgraph is executed. Thus, portions of a graph can beexecuted without the need to execute the entire graph.

There are various situations where executing an entire graph is notideal for a user. For example, if a user is editing an individual modulethe user may like to see the effects of the change only on this module'soutput. This holds especially true for scripting modules. Forcing a userto execute an entire graph when they are troubleshooting or iterating ontheir R, Python, SQL or other script may be excessive.

In another example, a user may not want to execute particular modules.For example, a user may not want to execute a writer module at the endof an experiment. Alternatively or additionally, a user may not want toexecute a long-running module or branch of an experiment. Alternativelyor additionally, a user may not want to execute a module or branch of anexperiment that: has a known error; is time consuming; is not needed foran immediate task; etc.

In another example, a user may want to execute only a particular clusterof modules. For example, the user may be able to determine that thelogic of the graph is incorrect and output is not as expected in somearea of the graph. In this case, the user may wish to fix and executethis block of the experiment, without needing to execute the entiregraph, to see if a change has remedied the issue.

In another example, a user may want to mark a non-deterministic moduleto be deterministic.

Various embodiments illustrated herein may facilitate certainfunctionality. For example, embodiments may be implemented to toggle thedeterministic behavior of a non-deterministic module. Embodiments may beimplemented to execute a single module in an experiment, using upstreamcached values (or otherwise obtained values) as inputs to the singlemodule. Embodiments may be implemented to execute a range of modules inan experiment, using upstream cached values (or otherwise obtainedvalues) as inputs and halting execution when the range is complete.Embodiments may be implemented to mark an individual module to notexecute. Embodiments may be implemented to exclude a branch of anexperiment from executing by choosing the stop point as mentioned above.Details are now illustrated.

User-directed graph execution enables users to choose which portions oftheir experiment to execute. This can be useful when a user is iteratingon a subset of their experiment, when they do not want to executenon-deterministic sections of their experiment, when they want toexclude failing modules or modules with side-effects etc.

Some embodiments may be based on Azure Machine Learning available fromMicrosoft Corporation of Redmond, Wash.

The following now illustrates where a user may want to execute only aparticular cluster of modules.

Referring now to FIG. 1A, a graph execution system 100 is illustrated.The graph execution system 100 includes a user interface 102. The userinterface 102 may be used by a user to select a group of modules toexecute from a graph 106. In particular, the system 100 includes storage104 which stores executable graphs. A graph 106, which includes variousmodules 107-1 through 107-12 can be rendered in the user interface 102.A user can select a sub-portion 108-1 of the graph 106 to execute In theembodiment illustrated, a user “rubber-bands” a sub-portion 108-1 oftheir graph, including modules 107-9 through 107-12 by dragging aboundary box 112 around the modules in the sub-portion 108-1.

However, selecting modules to be executed can be performed in a numberof different fashions, For example, FIG. 1B illustrates that each of themodules (referred to herein generically as 107) include a check box. Toselect an individual module to execute, an associated check box can beselected.

In another example, the user interface 102 may allow a user to selectmodules to execute by modifying a property. For example, a user couldright click a module, which could cause a selection of properties to bedisplayed. One of those properties could be a “run” property indicatingthat the module should be executed in a partial graph executionscenario.

In another example, a user may be able to use various keyboardshortcuts, such as selecting a module using a mouse or other pointer,and then using ctrl in combination with arrow keys to select variousmodules.

In still other embodiments, users may be able to use various pen andtablet selection tools to allow a user to select module.

In still other embodiments, users may be able to use gestures to selectmodules, such as touch pad gestures, or hand gestures when usingaugmented reality, projected interfaces such as the HoloLens systemavailable from Microsoft Corporation of Redmond, Wash., or otherinterfaces such as the Kinect interface available from MicrosoftCorporation of Redmond, Wash.,

When one or more modules are selected by a user, the user interface 102may include elements to allow a user to indicate that the modules shouldbe executed. For example, FIG. 2 illustrates a ‘Run Selected Module(s)’button 110 displayed in the user interface 102. The button 110 may bedisplayed when modules are selected. Alternatively or additionally, thebutton 110 may be displayed, but grayed out until modules are selected.Once modules are selected, the button 110 may become un-grayed on theuser interface 102 allowing the user to select the button 110 and causethe modules to be executed.

When a user selects the button 110, only the selected modules in thesub-portion 108-1 will run by a graph execution engine 116 configured toexecute graph modules, with the caveat that if required upstream data isnot available from some other source (such as a cache, user input,randomly generated values, etc.), some upstream modules may be executedas illustrated in more detail below.

Upstream data needed to execute modules in the sub-portion 108 may beobtained in a number of different ways. For example, in someembodiments, data can be obtained from previous executions of the graph106. In particular, the graph 106 may have been partially or fullyexecuted at a prior time. Data values generated during that ran may bestored in a cache 114. Thus, any needed data that is available in thecache 114 from a previous execution of all or portions of the graph 106may be used. For example, in the illustrated example, data values may beneeded from modules 107-7 and 107-8 to execute the sub-portion 108-1. Ifthe graph 106 has been executed previously, values from those modulesmay have been stored in the cache 114 and can be re-used to execute thesub-portion 108-1.

The cache 114 may be, for example, a table with a key and acorresponding value. The key identifies a module, and the valueidentifies a data value that the module has previously produced in aprevious run. In some embodiments, the key identifying the module may bea checksum value generated for the module. In some embodiments, theversion of a module is incorporated into the checksum value used as thekey. In this way a value generated by an appropriate version of anupstream module can be identified for use in a partial graph execution.

This works well for deterministic data values. However, it should beappreciated that in some embodiments, data generated by an upstreamgraph may be non-deterministic. For example, data values from upstreamgraphs may be generated using random numbers or operations. Data valuesmay be based on current time. Etc. For partial execution, however,embodiments may nonetheless use cached data with the knowledge that anydata produced by the partial execution may not be reliable or may be outof date. In fact, as illustrated in more detail below, in someembodiments, when a partial execution is performed, cached data formodules downstream from a sub-portion will be marked as “not run” andcached data for those modules may be invalidated.

Other methods may be used to obtain needed upstream data when performinga partial graph execution. For example, in some embodiments, the graphexecution engine 116 may determine that upstream data from modules 107-7and 107-8 is needed to execute the sub-portion 108-1. In someembodiments, the graph execution engine 116 can prompt the user usingthe user interface 102 to manually enter appropriate data values. Insome embodiments, the user can be prompted to enter certain types ofvalues. For example, if the module 107-8 ordinarily produces a string,the user may be prompted to enter a string. If the module 107-8ordinarily produces a floating point number, the user may be prompted toenter a floating point number. Etc. In some embodiments, the user may beprompted with suggested data values. These values could be predefinedvalues, randomly generated values, cached values produced by othergraphs, etc.

In some embodiments, the graph execution engine 116 can randomlygenerate upstream values and provide them automatically to modulesand/or present them to the user as suggested values. The values can begenerated using a schema. Thus, for example, a schema can indicate whattypes of values are produced by a given module. When values are needed,the values can be randomly generated using the schema. Thus, forexample, if the schema indicates that a string is generated by module107-8, then the graph execution engine can generate a random string whenexecuting the sub-portion 108-1 that can be provided to the module107-11.

In some embodiments, when values are needed from upstream modules toexecute a sub-portion 108-1 of a graph, links to values may be used. Forexample, the graph execution engine 116 may have URLs or other pointersthat direct the graph execution engine 116 to locations where samplevalues can be obtained. Alternatively or additionally, the userinterface 102 can be used to allow a user to specify links to values.

In some embodiments, the graph execution engine 116 may identify to theuser other modules that should be selected, to execute a sub-portion.For example. in FIG. 1A, the user selects sub-portion 108-1 to beexecuted. The execution engine 116 determines that for this sub-portionto be executed, modules 107-1, 107-2, 107-4, 107-6, 107-7, and 107-8also need to be executed. These can be suggested in the user interface102 to the user directing the user to also select these modules as partof a partial graph execution. If the user accepts these suggestions,then, as illustrated in FIG. 1C, the sub-portion 108-2 is selected to beexecuted instead of the sub-portion 108-1. In this way, all values fromupstream modules will be obtained. If the user chooses not to select oneor more of the suggested modules, data can be obtained in other ways,such as the ways suggested above.

In some embodiments, a user may not be given a choice of whether or notto execute upstream modules, but rather, any upstream modules will beexecuted if data is needed from those modules. In this case, while theuser has selected the sub-portion 108-1 to execute, the graph executionengine 116 will identify and execute the modules in the sub-portion108-2, potentially transparently to the user.

Embodiments are implemented where executing modules is limited by userselection. In particular, as illustrated above, non-upstream modules notselected by a user are not executed during a partial execution. Upstreammodules need not be executed in the partial execution when the data fromthose modules can be obtained elsewhere such as when cached data fromupstream modules is available from a previous execution, when user inputdata can be used in place of data produced by upstream modules, whenrandom data can be used in place of data from upstream modules, etc.Alternatively only those upstream modules that that produce data needed,either directly or indirectly, by user selected modules are executed.Embodiments are implemented where modules downstream from user selectedmodules are not executed. Thus, for example, FIG. 1D illustrates anexample where a sub-portion 108-3 is selected by a user. Thissub-portion 108-3 includes modules 107-4, 107-6, 107-8, and 107-11. Inthe illustrated example, modules 107-3, 107-5, 107-7, 107-10, and 107-12are not upstream from the user selected modules as they produce no datathat flows to the user selected modules in the sub-portion 108-3.Modules 107-1, 107-2 and 107-9 are upstream modules to the modules108-3. In some embodiments, these modules will also be executed when thesub-portion 108-3 is executed. However, in other embodiments, data forthese modules will be obtained from other sources as illustrated above.Execution of the sub-portion 108-3 stops at module 107-11 such thatdownstream modules, in this case module 107-12, are not executed.

In the example illustrated in FIGS. 1A-1D the user interface is coupledto an experimentation service 113. The experimentation service 113 is aservice layer of logic that resides between the user interface layer andthe job execution service 115 described below. The experimentationservice 113 may be constructed using processors, memory and softwarestored on the memory and executed by the processors, using firmware,using programmable logic devices, etc. The experimentation service 113filters out modules that should not be run in a partial executionscenario based on the modules selected by a user in the user interface102. Such filtering may filter out any modules not selected by a user inuser interface 102, or as illustrated above, any modules not selected bythe user and not needed as upstream nodes of modules selected by theuser. The job execution service 115 is the logic layer that takes agraph, parses it into jobs (individual steps), sends a job to the graphexecution engine 116, harnesses the result, and then repeats with thenext job. The job execution service 115 and graph execution engine 116may be constructed using processors, memory and software stored on thememory and executed by the processors, using firmware, usingprogrammable logic devices, etc.

In some embodiments, when a partial run is executed, cached module datadownstream from the selected modules becomes “suspect”. While cacheddata from a previous run may be available, it is out-of-date andpotentially incorrect. For this reason, in some embodiments, adownstream module will be marked as “Not Executed” when a partial run isinitiated. Thus for example, in the example illustrated in FIG. 1D, themodule 107-12 will be marked as “Not Executed” and any cached data forthe module 107-12 will not be used for other partial runs (although inthis example, that is irrelevant as the module 107-12 is not upstream toany other modules).

Another side effect of partial runs is their interaction with experimentrun history. In some systems, a partial run will not be distinguishablefrom a full experiment run in regards to the run history. If it fails,embodiments can display “Failed” in a run history (such as the runhistory 402 illustrated and discussed below in conjunction with FIG. 4),if it passes embodiments can display “Finished” in the run history, etc.

In some embodiments, a single module may be executed. This may beparticularly useful when executing scripting modules. Scripting modulesPython, R, SQL, etc.) generally go through several iterations as thecode is being written, While a user is working on each iteration,previously they needed to execute the entire graph in order to validatethat their incremental changes were behaving as expected. This is a timeconsuming process, particularly if the scripting module is deep in thegraph and has upstream modules that are re-executed due tonon-determinism.

Embodiments herein can allow a user to be able to make quick iterationson changes to their script, simply executing the module that they arechanging and using cached upstream values, or otherwise obtained valuesas illustrated above, then halting execution after the module completes.

FIG. 3 illustrates an example user interface that can be used to allow auser to make use of this functionality. FIG. 3 illustrates a userinterface element 302 that can be displayed in the user interface 102.In the example illustrated embodiments place an “execute script module”gesture in close proximity to the area the user will be working. In thisexample, this is the user interface element 302, which is a script box.A “Run Module” button 304 is placed in a properties pane 106, above thescript area 308.

When a user clicks run button 304, if cached input data is availablefrom the cache 114 from previous upstream execution, in someembodiments, it will be used regardless of the deterministic behavior ofany upstream module. This means that if non-deterministic modules arefeeding a script module, and the script module is executed inisolation—the non-deterministic module's cached values will be usedrather than re-executing. If upstream cached data is missing, then thenecessary upstream modules will be executed first prior to executing thescripting module.

After execution of the module in isolation, downstream data as well asrun history become suspect. To fit in with current behavior, one way toaddress downstream data is to remove it from the cache 114.

Run history can be updated to show that an incomplete passing or failingexperiment was executed. These can be shown by simply appending“(Partial Run)” to the status. For example, FIG. 4 illustrates a runhistory 402 that shows partial executions that can be displayed to auser in the user interface 102.

On the backend, communication from the user interface 102 to the graphexecution engine 116 describing that only a single module should beexecuted could be implemented in a number of ways. For example, in oneembodiment, embodiments may include a new graph execution call thattakes a second, argument describing which modules to execute.Alternatively or additionally, embodiments may implement anewserialized, module field to the graph. Each module will have an“ExcludeFromExecution” flag that defaults to false. Alternatively, oradditionally, embodiments may repurpose a “Mask” module field used formasking and do the same with it as described above for the“ExeludeFromExecution” field. “Masking” is the idea of commenting out ablock or excluding it from execution. Embodiments could “mask” aparticular module and run the entire experiment (i.e., not just apartial graph run)—but the masked module would not execute.

In the embodiments where a new serialized module field to the graph isimplemented, single module execution can be communicated from the userinterface 102 to the experimentation service 113 via a serialized moduleparameter in the graph (e.g., “ExcludeFromExecution”). Single moduleexecution flips these bits accordingly to convey to the experimentationservice 113 that potentially only a sub-portion (in this case, one) ofmodules should be executed. Experimentation service 113 code honorsthese flags, only sending a sub-portion of module tasks to the jobexecution service 115 in a submitted job. Thus, the experimentationservice 113 filters out modules that should not be run in a partialexecution scenario. The job execution service 115 is the logic layerthat takes a graph, parses it into jobs (individual steps), sends a jobto the graph execution engine 116, harnesses the result, and thenrepeats with the next job.

On the user interface side, when an individual module is being executed,the graph being sent to experimentation service 113 for execution hasthe “ExcludeFromExecution” field flipped to true with the exception ofthe single module being executed. The ‘Run Module’ button 304 is locatedin the properties pane 306 for the scripting module and when clicked,will cause the graph to be forwarded to the graph execution engine 116,such as by sending to a REST API used by a ‘Run’ method—after the graphhas been updated to indicate which modules should be excluded fromexecution.

The following now illustrates details with respect to allowing a user tomanage execution of non-deterministic modules. Non-deterministic moduleswill have different outputs on different runs, even when inputs intothose modules are the same between the different runs. This could becaused due to random functions, race conditions, approximationtechniques. etc.

In some graph systems there are modules (e.g., I/O modules) that willexecute on every experiment executed, regardless of whether or not thedata they are using or outputting has changed. In some embodimentsillustrated herein, as shown in FIG. 5, users will be presented with acheck box or other appropriate interface, such as the check box 502,such as in the properties pane for non-deterministic modules (includingcustom modules). If a user selects the check box 502, then the module isnot re-executed and previously cached data may be used. To maintainbackwards compatibility and also preserve semantics that are generallythought to be correct, in some embodiments, the default state of thischeck box will be unchecked (i.e. non-deterministic behavior).

In the event that this box is checked by a user, but parameter valueshave been changed on the module or new data is being fed into it, thecheckbox will not be honored and the module will re-execute (similar tothe behavior of deterministic modules). In addition, if previous runresults are not available for the module then it will also execute.

In the illustrated example, the check box 502 is displayed as thebottom-most parameter in the properties pane 506 of anynon-deterministic module:

In some embodiments, the parameter being exposed to toggle determinismwill not be a parameter on the module in the traditional sense. Rather,the user interface can automatically add this parameter when displayingthe properties pane of a non-deterministic module. This is done toensure that toggling this parameter will not invalidate any existingcache. The user interface stores the state of this parameter as a newmodule field in the serialized experiment graph. When the graph ispassed to the experimentation service 113 for execution, experimentationservice 113 behavior will be altered to key off of the state of thisfield rather than the deterministic setting on the module itself. Thegenerated module task will set the deterministic flag for the jobexecution service 113 appropriately. For the job execution service 113to honor this setting, any cached data is available for this module. Thejob execution service 113 will unconditionally store cached outputsafter execution, irrespective of the deterministic state of the task.

Some embodiments allow for a user to mark a module as “do-not-execute”.This has the effect of halting graph execution for that particularbranch. This may be done to disable modules with side-effects, todisable branches of an experiment that are erroring out, etc.

The following discussion now refers to a number of methods and methodacts that may be performed. Although the method acts may be discussed ina certain order or illustrated in a flow chart as occurring in aparticular order, no particular ordering is required unless specificallystated, or required because an act is dependent on another act beingcompleted prior to the act being performed.

Referring now to FIG. 6, a method 600 is illustrated. The method 600includes acts for executing a user selected portion of an executablegraph. The method 600 includes, for an executable graph, the executablegraph comprising executable modules, identifying a user selectedsub-portion of the executable graph (act 602).

The method 600 further includes determining that data is needed fromupstream modules in the graph to execute the sub-portion of theexecutable graph (act 604).

The method 600 her includes obtaining the needed data (act 606). Thismay be done in some embodiments without executing any modules that donot need to be executed to obtain the needed data. In some embodiments,this may be done by not executing any modules not selected by the user.For example, these embodiments could use cached data, randomly generateddata, and/or user input data.

The method 600 further includes executing the user selected sub-portionof the graph in isolation from other portions of the executable graph(act 608). In some embodiments, this includes halting execution at theend of the user selected sub-portion of the graph.

The method 600 may be practiced where obtaining the needed datacomprises obtaining cached values from one or more previous executionsof relevant upstream modules.

The method 600 may further include identifying for the user additionalmodules that need to be executed to obtain at least a portion of theneeded data and suggesting to the user that the user select thosemodules as well.

The method 600 may further include identifying for the user additionalmodules that need to be executed to obtain at least a portion of theneeded data and automatically selecting the additional modules for theuser.

The method 600 may be practiced where obtaining the needed datacomprises forcing use of cached values obtained from one or moreprevious executions of non-deterministic modules to be used, even thoughupstream modules produced non-deterministic results.

The method 600 may be practiced where obtaining the needed datacomprises prompting a user to identify values. For example, prompting auser to identify values may include prompting a user to manually inputvalues. Alternatively or additionally, prompting a user to identifyvalues includes prompting a user to accept suggested input values.Alternatively or additionally, prompting a user to identify valuesincludes prompting a user to identify a pointer to where values can beobtained. For example, the user can provide a URL or other pointer to alocation where data can be obtained.

The method 600 may be practiced where obtaining the needed datacomprises using randomly generated data. In some embodiments, therandomly generated data is generated according to a schema.

Referring now to FIG. 7, a method 700 is illustrated. The method 700includes acts for executing a user defined portion of an executablegraph. The method includes providing to a user a graphicalrepresentation of an executable graph, the executable graph comprisingexecutable modules (act 702).

The method 700 further includes receiving from the user a selection of asub-portion of the executable graph (act 704).

The method 700 further includes executing the user selected sub-portionof the graph in isolation from other portions of the executable graph(act 706).

The method 700 may further include determining that data is needed fromupstream modules in the graph to execute the sub-portion of theexecutable graph and obtaining the needed data. In some suchembodiments, the method 700 may be practiced where obtaining the neededdata comprises obtaining cached values from one or more previousexecutions of relevant upstream modules. Alternatively or additionally,obtaining the needed data may include prompting a user in the userinterface to identify values. Prompting a user to identify values mayinclude prompting a user to manually input values. Alternatively oradditionally, prompting a user to identify values may include promptinga user to accept suggested input values. Alternatively or additionally,prompting a user to identify values may include prompting a user toidentify a pointer to where values can be obtained.

The method 700 may further include identifying for the user in the userinterface, additional modules that need to be executed to obtain atleast a portion of the needed data and suggesting to the user that theuser select those modules as well.

The method 700 may further include identifying for the user in the userinterface, additional modules that need to be executed to obtain atleast a portion of the needed data and automatically selecting theadditional modules for the user.

Further, the methods may be practiced by a computer system including oneor more processors and computer-readable media such as computer memory.In particular, the computer memory may store computer-executableinstructions that when executed by one or more processors cause variousfunctions to be performed, such as the acts recited in the embodiments.

Embodiments of the present invention may comprise or utilize a specialpurpose or general-purpose computer including computer hardware, asdiscussed in greater detail below. Embodiments within the scope of thepresent invention also include physical and other computer-readablemedia for carrying or storing computer-executable instructions and/ordata structures. Such computer-readable media can be any available mediathat can be accessed by a general purpose or special purpose computersystem. Computer-readable media that store computer-executableinstructions are physical storage media. Computer-readable media thatcarry computer-executable instructions are transmission media. Thus, byway of example, and not limitation, embodiments of the invention cancomprise at least two distinctly different kinds of computer-readablemedia: physical computer-readable storage media and transmissioncomputer-readable media.

Physical computer-readable storage media includes RAM, ROM, EEPROM,CD-ROM or other optical disk storage (such as CDs, DVDs, etc), magneticdisk storage or other magnetic storage devices, or any other mediumwhich can be used to store desired program code means in the form ofcomputer-executable instructions or data structures and which can beaccessed by a general purpose or special purpose computer.

A “network” is defined as one or more data links that enable thetransport of electronic data between computer systems and/or modulesand/or other electronic devices. When information is transferred orprovided over a network or another communications connection (eitherhardwired, wireless, or a combination of hardwired or wireless) to acomputer, the computer properly views the connection as a transmissionmedium. Transmissions media can include a network and/or data linkswhich can be used to carry or desired program code means in the form ofcomputer-executable instructions or data structures and which can beaccessed by a general purpose or special purpose computer. Combinationsof the above are also included within the scope of computer-readablemedia.

Further, upon reaching various computer system components, program codemeans in the form of computer-executable instructions or data structurescan be transferred automatically from transmission computer-readablemedia to physical computer-readable storage media (or vice versa). Forexample, computer-executable instructions or data structures receivedover a network or data link can be buffered in RAM within a networkinterface module (e.g., a “NIC”), and then eventually transferred tocomputer system RAM and/or to less volatile computer-readable physicalstorage media at a computer system. Thus, computer-readable physicalstorage media can be included in computer system components that also(or even primarily) utilize transmission media.

Computer-executable instructions comprise, for example, instructions anddata which cause a general purpose computer, special purpose computer,or special purpose processing device to perform a certain function orgroup of functions. The computer-executable instructions may be, forexample, binaries, intermediate format instructions such as assemblylanguage, or even source code. Although the subject matter has beendescribed in language specific to structural features and/ormethodological acts, it is to be understood that the subject matterdefined in the appended claims is not necessarily limited to thedescribed features or acts described above. Rather, the describedfeatures and acts are disclosed as example forms of implementing theclaims.

Those skilled in the art will appreciate that the invention may bepracticed in network computing environments with many types of computersystem configurations, including, personal computers, desktop computers,laptop computers, message processors, hand-held devices, multi-processorsystems, microprocessor-based or programmable consumer electronics,network PCs, minicomputers, mainframe computers, mobile telephones,PDAs, pagers, routers, switches, and the like. The invention may also bepracticed in distributed system environments where local and remotecomputer systems, which are linked (either by hardwired data links,wireless data links, or by a combination of hardwired and wireless datalinks) through a network, both perform tasks. In a distributed systemenvironment, program modules may be located in both local and remotememory storage devices.

Alternatively, or in addition, the functionality described herein can beperformed, at least in part, by one or more hardware logic components.For example, and without limitation, illustrative types of hardwarelogic components that can be used include Field-programmable Gate Arrays(FPGAs), Program-specific Integrated Circuits (ASICs), Program-specificStandard Products (ASSPs), System-on-a-chip systems (SOCs), ComplexProgrammable Logic Devices (CPLDs), etc.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or characteristics. The described embodimentsare to be considered in all respects only as illustrative and notrestrictive. The scope of the invention is, therefore, indicated by theappended claims rather than by the foregoing description. All changeswhich come within the meaning and range of equivalency of the claims areto be embraced within their scope.

What is claimed is:
 1. A method of executing a user defined portion ofan executable graph, the method comprising: providing to a user agraphical representation of an executable graph, the executable graphcomprising executable modules; receiving from the user a selection of asub-portion of the executable graph; and executing the user selectedsub-portion of the graph in isolation from other portions of theexecutable graph.
 2. The method of claim 1, further comprising:determining that data is needed from upstream modules in the graph toexecute the sub-portion of the executable graph; and obtaining theneeded data.
 3. The method of claim 2, wherein obtaining the needed datacomprises obtaining cached values from one or more previous executionsof relevant upstream modules.
 4. The method of claim 2, whereinobtaining the needed data comprises prompting a user in the userinterface to identify values.
 5. The method of claim 4, whereinprompting a user to identify values comprises prompting a user tomanually input values.
 6. The method of claim 4, wherein prompting auser to identify values comprises prompting a user to accept suggestedinput values.
 7. The method of claim 4, wherein prompting a user toidentify values comprises prompting a user to identify a pointer towhere values can be obtained.
 8. The method of claim 1, furthercomprising identifying for the user in the user interface, additionalmodules that need to be executed to obtain at least a portion of theneeded data and suggesting to the user that the user select thosemodules as well.
 9. The method of claim 1, further comprisingidentifying for the user in the user interface, additional modules thatneed to be executed to obtain at least a portion of the needed data andautomatically selecting the additional modules for the user.
 10. Acomputer system comprising: one or more processors; and one or morecomputer-readable media having stored thereon instructions that areexecutable by the one or more processors to configure the computersystem to execute a user selected portion of a graph, includinginstructions that are executable to configure the computer system toperform at least the following: providing to a user a graphicalrepresentation of an executable graph, the executable graph comprisingexecutable modules; receiving from the user a selection of a sub-portionof the executable graph; and executing the user selected sub-portion ofthe graph isolation from other portions of the executable graph.
 11. Thesystem of claim 10, wherein one or more computer-readable media havestored thereon instructions that are executable by the one or moreprocessors to configure the computer system to: determine that data isneeded from upstream modules in the graph to execute the sub-portion ofthe executable graph; and obtaining the needed data.
 12. The system ofclaim 11, wherein obtaining the needed data comprises prompting a userin the user interface to identify values.
 13. The system of claim 12,wherein prompting a user to identify values comprises prompting a userto manually input values.
 14. The system of claim 12, wherein promptinga user to identify values comprises prompting a user to accept suggestedinput values.
 15. The system of claim 12, wherein prompting a user toidentify values comprises prompting a user to identify a pointer towhere values can be obtained.
 16. The system of claim 10, wherein one ormore computer-readable media have stored thereon instructions that areexecutable by the one or more processors to configure the computersystem to identify fir the user in the user interface, additionalmodules that need to be executed to obtain at least a portion of theneeded data and suggesting to the user that the user select thosemodules as well.
 17. The system of claim 10, wherein one or morecomputer-readable media have stored thereon instructions that areexecutable by the one or more processors to configure the computersystem to identify for the user in the user interface, additionalmodules that need to be executed to obtain at least a portion of theneeded data and automatically selecting the additional modules for theuser.
 18. A computer system, the computer system comprising: a userinterface, wherein the user interface is configured to display anexecutable graph and to receive user input selecting a sub-portion ofthe graph, and wherein the user interface is configured to indicate toprovide an indication of the sub-portion of the graph to a graphexecution engine, such that the graph execution engine can execute thesub-portion of the graph in isolation from e or more other portions ofthe graph.
 19. The system of claim 18, wherein the user interface isconfigured to receive user input to rubber-band a sub-portion
 20. Thesystem of claim 18, wherein the user interface is configured to receiveuser input selecting individual modules of the graph to execute.